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METHOD AND APPARATUS FOR PERMITTING A 
RADIO TO ORIGINATE AND RECEIVE DATA MESSAGES IN A 
DATA COMMUNICATIONS NETWORK 



5 Related U.S. Applications 

This application is related to United States Patent Application 
Serial No. 08/514,736 entitled "Method and Apparatus for Modifying 
a Standard Internetwork Pro tocol-Layer Header' which is assigned to 
10 the assignee of the present invention and incorporated herein by 
reference. 



FIELD OF THE INVENTION 



15 The present invention relates to the transmission of data 

packets over a data communications network that includes a radio 
link, and more particularly, to a communications protocol which 
permits radios in the data communications network to originate and 
receive data messages. 



20 



BACKGROUND AND STTMMARY OF THE INVENTION 



The open systems interconnection (OSI) model divides the 
communications process into the seven layers illustrated in Figure 

25 1(a). Certain communications tasks are assigned to certain layers 
and the output of each layer has a precise format established for it. 
Data from an application or process running on a first host computer 
A passes through each OSI layer on its way to communications 
network. As the information descends through each layer, it 

30 undergoes a transformation that prepares it for processing by the 
next layer. Upon reaching the bottom layer, data is tasked to the 
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physical medium of the network as a serial stream of bits represented 
by a changing signal, i.e., changing volts, radio frequency waves, or 
light pulses. After receiving the changing signal at a second host 
computer (host B), the stream travels in reverse order through the 
5 seven OSI layers. 

Layer protocols and interfaces therebetween are defined which 
provide specifications for communication between a process or 
program being executed on one host computer's operating system and 
another process or program running on another computer. 

10 Transmission control protocol/internet protocol (TCP/TP) are two 
protocols that are part of a protocol suite or family of protocols 
layered and designed to connect computer systems that use different 
operating systems and network technologies. Figure 1(b) illustrates 
conceptual layers for TCP/IP somewhat analogous to the OSI model 

15 of Figure 1(a) as well as the format of objects passed between 
adjacent protocol layers. 

TCP/TP is a four layer protocol suite (the hardware layer is not 
counted) which facilitates the interconnection of two or more 
computer systems on the same or different networks, and in certain 

20 networks such as the Internet, is a requirement for interoperability. 
The four layers comprise two independent protocols: TCP, which can 
be used to access applications on other systems within a single 
network, and EP, which permits identification of source and 
destination addresses for communication between systems on 

25 different networks. The present invention relates generally to the 
latter IP protocol. 

At the internet layer, the internet protocol permits 
identification of source and destination addresses for communication 
over physical networks. The fundamental internetwork service 

30 consists of a packet delivery system, and the internetwork protocol 
(IP) defines that delivery mechanism, i.e., the basic unit of data 
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transfer. Thus, the EP specifies the exact format of all data as it 
passes across a TCP/IP internet. The IP software also performs a 
routing function by choosing a path over which data will be sent. 
The basic data transfer unit is often called a "datagram" 
5 (similar to a typical physical network "frame") and is divided into 
header and data areas. A datagram is shown in Figure 2(a). The 
header contains (1) source and destination addresses and (2) a type 
field that identifies the contents of the datagram. The IP protocol 
only specifies the header-format including-the-source and destination 

10 IP addresses; it does not specify the format of the data area. 

Figure 2(b) shows a standard IP header consisting of a number 
of predefined fields. The first four bit field VERS contains the 
version of the IP protocol that was used to create the datagram. The 
VERS field is used to verify that the sender, receiver, and any 

15 gateways in between, agree on the format of the datagram. The four 
bit header length field HLEN provides the datagram header length 
measured in multiples of thirty-two bit words. The TOTAL LENGTH 
field gives the length of the IP datagram (both header and data) 
measured in octets. By subtracting the length of the header from the 

20 total length found in the TOTAL LENGTH field, the size of the data 
area can be calculated. The eight bit SERVICE type field specifies 
how the datagram should be handled. 

The three fields— IDENTIFICATION, FLAGS, and FRAGMENT 
OFFSET - control fragmentation and reassembly of datagrams. 

25 Since an IP datagram may not fit into one physical frame data area, 
(a constraint of the physical network), the datagram may be divided 
into smaller pieces called "fragments" with the process of dividing a 
- datagram being known as "fragmentation." Fragment size is chosen 
so that each fragment can be shipped across the underlying network 

30 in a single frame. Each fragment has the same format as the 

original datagram. Accordingly, each fragment contains a header 
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that duplicates most of the original datagram header except for a bit 
in the FLAGS field. The FLAGS bit identifies the datagram as a 
fragment which carries a data amount up to a total length that is 
smaller than the TnaviTTinm transfer unit permitted over the network. 
5 Once a datagram is fragmented, the fragments travel as separate 
datagrams all the way to the ultimate destination where they must 
be reassembled. The field IDENTIFICATION contains a unique 
integer that identifies the datagram to allow the destination to know 
which of the arriving fragments belong to which datagrams. As the 

10 fragment arrives, the destination uses the IDENTIFICATION field 
along with the datagram source address to identify the datagram. 
The FRAGMENT OFFSET specifies the offset in the original 
datagram of the data being carried in the fragment measured in 
units of eight octets starting at offset zero. To reassemble the 

15 datagram, the destination must obtain all fragments starting with 
the fragment that has offset "zero" through the fragment with the 
highest offset. The FLAGS field controls fragmentation with one of 
the bits being called the "more fragments bit." 

The TIME TO LIVE (TTL) field specifies how long in seconds 

20 the datagram is allowed to remain in the Internet system and is 
normally used as a count value so that time does not have to be 
synchronized across the network. The PROTOCOL field specifies 
which high level protocol was used to create the message being 
carried in the data area of the datagram. In essence, the value of the 

25 PROTOCOL field specifies the format of the data area. The field 
HEADER CHECKSUM is formed by treating the header as a 
sequence of sixteen bit integers, adding them together using one's 
complement arithmetic, and taking the one's complement of the 
result. Fields SOURCE IP ADDRESS and DESTINATION IP 

30 ADDRESS contain the thirty-two bit IP addresses of the datagram 
sender and intended recipient. Thus, the IP addresses specify the 
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original source and ultimate destination. The IP OPTIONS and 
PADDING fields are included mainly for testing and debugging of the 
network. 

Since each layer of the OSI and TCP/IP models adds header 
5 type information, there is a considerable amount of "overhead'* added 
to the originally transmitted data. There is also the significant 
processing overhead associated with packetizing data for network and 
internetwork transmission. Because the network and internetwork 
packet header is meant to be used across a variety of applications, 

10 the standard IP packet header contains fields that may not be used 
or needed in a particular application. While these extra fields may 
not be a problem in high bandwidth communication environments, 
they present a significant problem when used in a radio frequency 
(RF) communications environment. RF bandwidth is a precious 

15 resource in such applications as public safety trunked radio and 
cellular radio. Any additional overhead bits/fields decreases the 
amount of actual data that can be sent in the given unit of time 
therefore lowering data throughput. Thus, one objective of the 
present invention is to minimize the overhead required to send a 

20 packet of data over an RF data rmriTrmnications network but at the 
same time permit thos e RF data cp™™"*" cations to be compatible 
with industry accepted internetwork protocol standards like IP and 
TCP/IP^ 

A method and apparatus which permit internetworked 
25 communications between computers in a radio frequency 

communications network and computers connected to a wireline 
network and minimizes protocol overhead while maintaining 
compatibility with conventional TCP/IP protocols is disclosed in 
copending, commonly assigned U.S. Patent Application Serial No. 
30 08/514,736. Unnecessary IP header bits are removed before packets 
are transmitted over the radio network to conserve RF channel 
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bandwidth. Knowledge of information already present in the data 
link layer of the RF channel communications protocol is used to omit 
unnecessary or redundant fields in the standard IP header of the 
network layer. Enough information is preserved in the reduced IP 
5 network header so that the standard IP header may be 

reassembled/reconstructed. This reduced IP radio network layer 
header (RNLH) is commonly referred hereafter as a long RNLH. 

In a conventional radio data communications network, the 
radio acts primarily as a conduit processing specific frames of data at 

10 the data link layer between computer terminals. For this reason, the 
radio usually only supports the data link and physical link layers of 
the OSI model. Recently, however, it is desirable for the radio to 
function like any other computing device in a computer network. For 
example, it is desirable to program or reprogram the "personality" of 

15 an individual radio directly over the air without having to hardwire 
connect the radio to some other programming device. Text messaging 
with the radio is also a desirable feature for some radios. In 
addition, multiple "end" computing entities may be associated with a 
single radio, including for example, a radio data terminal, an 

20 automatic vehicle locator device (AVL), a radio group, a radio data 
terminal group, etc. 

Conventionally, the radio is not the final destination for any 
specific data messages; nor does the radio originate data messages. 
The present invention "elevates" the radio so that it functions like 

25 any other "end computing device" in the network. However, to 

obtain this elevated status and these benefits, the radio must support 
the network layer protocol which means that the radio must accept 
and generate IP datagrams. Thus, to function as an end computing 
device, the radio "supports" the network layer by (1) processing 

30 network layer headers attached to network layer messages (rather 
than just passing them through as raw data) and (2) generating a 
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compatible network layer header and attaching it to all data message 
which the radio originates. 

While the radio cotdd be extensively reprogrammed the radio 
and existing radio communications protocols modified for the radio to 
5 function at the network layer, the present invention achieves this 
goal with minimal ^programming and RF protocol modification. , 
Specifically, the radio attaches a "short'* radio network layer header 
to data messages it originates. The short radio network layer header 
contains the mmimnTn data necessary for the radio-to -provide 

10 network layer support without having to store data and fill-in IP 
header fields that are non-essential for the radio's co mmuni cation, 
data processing, and networking needs. 

In a preferred embodiment of the present invention, the short 
network layer header includes only the same first several fields of a 

15 longer radio network layer header referred to above and described in 
detail in the above-identified application. The other fields in the long 
radio network layer header are used for example in data 
communications with radio data terminals (RDTs) where data 
messages are transceived over the radio network via radios connected 

20 to the RDTs. The short header allows the radios to support 
messaging at the network layer level with minimum impact on 
existing radios while at the same time adhering to the well 
established OSI model for data communications. In addition, the 
short radio network layer header is "open-ended" so that additional 

25 fields may be added to the short radio network layer header to adapt 
to changing communications needs and accommodate advances in 
communications protocols. 

BRIEF DESCRIPTION OF T HE DRAWINGS 



30 
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These objects and advantages, as well as others will be better 
understood from the following detailed description taken in 
conjunction with the accompanying drawings in which: 

5 FIGURE 1(a) is a diagrammatic view of an open systems 

interconnection (OSD model; 

FIGURE 1(b) is a diagram of the conceptual layers of the 
TCP/TP protocol indicating objects which are passed between layers; 

10 

FIGURE 2(a) is a diagrammatic view of a standard IP 
datagram; 

FIGURE 2(b) is a diagrammatic view of a standard IP header; 

15 

FIGURE 3 is a function block diagram of an internetwork that 
includes an Ethernet network coupled to an RF data network 
through a gateway; 

20 FIGURE 4 is a high level diagram showing potential data 

communications between the data gateway, a radio, and a radio data 
terminal (RDT); 

FIGURES 5(a) and 5(b) are diagrams showing short and long 
25 radio network layer headers in accordance with the present 
invention; 

FIGURE 6 is a flowchart diagram illustrating procedures 
performed at the network and data link layer protocols for data 
30 transmissions originating from either the radio or some other device 
associated with the radio destined for a wireline data gateway; 
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FIGURE 7 is a flowchart diagram illustrating the procedures 
for generating a short radio network layer header; 

FIGURE 8 is a flowchart diagram illustrating the procedures 
5 for generating a long radio network layer header; 

FIGURE 9 is a flowchart diagram illustrating the procedures 
for converting a radio network layer header to an IP packet header at 
the data gateway; 



10 



15 



FIGURE 10 is a flowchart diagram illustrating performed 
transmissions procedures at the network and data link layer levels 
for data transmissions originating from the data gateway destined for 
either the radio or some other device associated with the radio; 

FIGURE 11 is a flowchart diagram illustrating the procedures 
for converting an IP packet header to a radio network layer header at 
the data gateway; and 



20 FIGURE 12 is a flowchart diagram illustrating the procedures 

for converting a radio network layer header to an IP header at the 
radio data terminal. 



25 



DETAILED DESCRIPTION OF THE INVENTION 



In the following description, for purposes of explanation and 
not limitation, specific details are set forth such as particular circuits, 
protocols, techniques, etc. in order to provide a thorough 
understanding of the present invention. However, it will be apparent 
30 to one skilled in the art that the present invention may be practiced 
mother embodiments that depart from these specific details. In 
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other instances, detailed descriptions of well-known methods, devices, 
protocols, and circuits are omitted so as not to obscure the description 
of the present invention with unnecessary detail. 

Figure 3 shows two different types of networks including an 
5 Ethernet network 12 and an RF data network 10. No single type of 
network is best for all situations/applications. Ethernet networks 
perform well when used to connect computers physically located at 
the same location. However, an RF data network is best suited for 
mobile/portable radio data terminals (RDTs) where communications 

10 with other radio data terminals (and as described below, other host 
computers) are over a wireless, radio frequency (RF) physical 
communications medium. Host computers A, B, and N (16, 18, and 
20) use Ethernet cable 14 as their physical communications medium 
and use Ethernet addresses and protocol to communicate. The radios 

15 28 and 30, radio data terminals 32 and 35, and automatic vehicle 
locators (AVLs) 34 and 36 use radio frequencies as their physical 
communications medium and RF data network addresses and 
protocols to communicate with one or more sites 22, 23. 

In the present invention, the radio itself is a potential data 

20 message end-receiver and data message originator. The radio also 
supports one or more other data message end-receivers and 
originators such as physical devices like the RDT and AVL, and 
"software" devices such as a text message feature, over the air radio 
programming, a software -configured radio group, a software- 

25 configured RDT group, etc. Hereafter, such hardware and software- 
based data end-receivers/originators including the radio are referred 
to generally as network layer data transceivers because they receive 
and originate messages at the network layer. For simplicity, 
however, the invention is described using the non-limiting example of 

30 a radio and radio data terminal (RDT) combination. 
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The Ethernet network 12 and the radio data network 10 are 
"internetworked" using a data gateway 40 and a data interface 
module 38. In general terms, data gateway 40 provides the interface 
for translating messages between both networks. The network layer, 
5 as shown in the OSI model in Figures 1(a) and 1(b), is just above the 
data link layer and provides consistent addressing, protocol, and 
interface across the internet Although the network layer addresses 
are consistent across the internet, they are converted to data link 
layer addresses specific to the network type to actually send data 

10 across a specific network. The data gateway 40 connects to the host 
computers 16, 18, and 20 on Ethernet network coaxial cable 14 using 
non-proprietary, standardized protocols such as TCP/DP. To interface 
with the RF data network, the data gateway 40 supports network 
driver software that functions at both the network and data link 

15 layers to make necessary protocol conversions. 

Referring to Figure 3, the following describes an example data 
flow from host computer 16 on the wireline Ethernet Network to the 
radio 28 on the RF Data Network. The host 16 sends a message to 
the data gateway 40. The data gateway 40 sends a call request to 

20 the data interface module 38, The data interface module 38 sends 
the call request to the site 22 where the radio 28 is located. The site 
22 instructs the radio 28 over an RF control channel to which the 
radio is tuned to tune to an RF working channel to receive the 
message. The site 22 returns the RF working channel assignment to 

25 the data interface module 38. The data interface module 38 connects 
a data path between the data gateway 40 and the RF working 
channel and notifies the data gateway 40. 

The data gateway 40 breaks the message down into packets 
and sends the first burst of packets to the site 22. The site 22 

30 forwards the burst to the radio as over an RF channel it receives it. 
After the radio 24 receives the entire burst, it performs CRC-type 
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error checking and if there are no errors, it sends an acknowledged 
message (ACK) at the data link layer back to the data gateway 40 
(via the site 22), informing it of the packets that the radio correctly 
received. If necessary, the data gateway 40 sends another burst 
5 containing packets that the radio did not correctly receive and 
packets that the data gateway 40 has not previously sent This 
process continues until the radio receives the entire message or until 
the data gateway 40 exhausts a preset number of retries. The radio 
processes the received data to determine whether the message is for 
10 it, and if not, routes the message without further processing to, for 
example, the RDT. 

The following describes the data flow from the radio to host 
computer. The radio 28 informs the site 22 over the RF control 
c hann el that it has a message and requests an RF working channel. 
15 The site 22 assigns an available RF working channel and informs 
the radio 28. The site 22 sends the call assignment to the data 
interface module 38 which sends it on to the data gateway 40. i Rre- 
ihila gaLcwaji 40 infuxuib Qie data in l eifa u o modulo 38/ind t he data 
interface module 38 sets up a data path between the data gateway 40 
20 and the RF working channel. The radio 28 breaks the message down 
into packets and sends the first burst of packets to the site 22. The 
site 22 forwards the burst to the data gateway 40 as it receives it. 
After the data gateway 40 receives the entire burst, it sends an ACK 
back to the radio, informing it of the packets that the data gateway 
25 40 correctly received. If necessary, the radio sends another burst 

containing packets that the data gateway 40 did not correctly receive 
and packets that the radio has not previously sent. This sequence 
continues until the data gateway 40 receives the entire message or 
until the radio exhausts its retries. If the data gateway 40 
30 successfully received the message, the data gateway 40 sends the 
message to the host computer 16. 
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In communicating with the Ethernet network, the data link 
layer of the data gateway uses Ethernet II protocol also known as 
IEEE 802.3 DDL The network layer uses the standard internet 
protocol (IP) described, for example, in the text by Douglas E. Comer 
5 entitled "Internetworking with TCP/IP, VoL 1." Used above the 
network layer are Tiost-to-host" conversations between a host 
computer (16-20) and a radio data terminal (30-36) which follow 
transport layer protocols. Any headers that they use above the 
network and transport layers are simply passed as data through the 

10 network and are not of particular interest to the present invention. 
At the data link layer, the data gateway 40 and host 
computers 16-20 communicate using Ethernet addresses and address 
resolution protocol (ARP) to discover each other's Ethernet addresses 
based on their IP addresses. The network layer uses the IP address 

15 to decide where to route the message next. For messages originating 
from a host computer, the host computer addresses a radio (or group 
of radios) using a unique IP address assigned to each radio (and 
group). Normally, each host computer has a single entry added to its 
routing table instructing it to use the data gateway 40 as a next 

20 gateway for messages being sent to any destination on the RF data 
network 10. For messages from a radio to a host, the data gateway 
40 receives the message, examines the IP address, and forwards the 
message on to the appropriate host computer. 

Figure 4 shows possible communication paths between the 

25 data gateway, radio, and radio data terminal, and the radio data 
terminal or radio and the data gateway. At the physical layer 
between the data gateway and the radio, the communications media 
is a radio frequency communications channel. Between the radio and 
the radio data terminal, the physical layer is an RS-232 serial link. 

30 At the data link layer, the "logical link" between the data gateway 
and the radio is a non-standard, hardened protocol designed 
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specifically for limited bandwidth RF working channels assigned by 
sites 22 or 23 referred to as data channel signalling (DCS). The data 
link layer on the radio network uses a medium access control 
sublayer network driver, indicated in Figure 4 generally as radio 
5 data interface (HDD, designed for personal computers running MS- 
DOS which converts between standard EP headers and RF data 
network layer headers* At the network layer, the standard IP 
network header protocol is modified/reduced to a radio network layer 
header-as-will be described in further detail below. As indicated 
10 generally in Figure 4, a data packet from the data gateway can be 
destined for the radio or pass through the radio to the radio data 
terminal. Alternatively, data packets can be originated at both the 
radio data terminal and the radio and routed to the data gateway. 



(RNL) Header before datagra ms are sent across the Radio Data 
Network. A long Radio Network Layer header is generated by 
omitting certain fields of information in the standard IF header and 
using just the version, unused, identification, more fragments, 

20 fragment offset, protocol, and extended address fields (see Figure 2B). 
The long Radio Network Layer Header is shown in Figure 6(a) and is 
stripped of unnecessary fields. The long RNL header is used fo r 
exa^^lejor data communications between RDTs and the data 
jB g^teway 40 over the RF lin k, 

25 Shortening the network layer header to either the long or short 

radio network layer header reduces unnecessary overhead 
information on bandwidth limited RF channels and improves data 
transmission efficiency/speed over the RF Data Network. Moreover, 
the present invention permits a proprietary radio network layer 

30 protocol that is uniquely desirable in an RF environment to be used 
with and support standard IP features up through the network layer. 



15 



For the network layer protocol, a standard Internet Protocol 
(IP) Headers is converted to a modified "long" Radio Network Layer 
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As a result, standard computer communications protocols can be used 
within a radio data network while minimizing bandwidth use on the 
radio channel and permitting the use of a protocol op timiz ed 
(hardened) for the RF environment. 
5 The Short Radio Network Layer Header is shown in Figure 

6(b). Significantly, both the short and long radio network layer , 
headers use the same first five fields. However, additional fields of 
the long RNL header including the identification (ID), more 
fragments (MF), and fragment offset fields are not used by the radio, 

10 and therefore, are not included in the short RNL header. The first 
fields (e.g., five fields) of the radio network layer header are fixed 
with the basic information needed to support network layer 
communications regardless of the ultimate length of the radio 
network layer header. Because the header including these five fields 

15 is short, it has minimal impact on existing radios and radio protocols. 
In addition, future changes to the network layer protocol that 
inevitably will occur are easily accommodated at the "back-end" of 
the header. In other words, additional fields may be added to the 
basic short radio network layer header fields to support additional 

20 network functions required by new network layer protocols. The 
immediate example of this is the extra three fields added to create 
the long network layer header shown in Figure 5(a). With the "core" 
information at the front of the header, future enhancements and 
changes may be attached to the back end of the header without 

25 affecting the radio since the radio can ignore all of the fields in the 
RNL header after reading the last field in the short RNL header. In 
this way, the radio is not a bottleneck to future modifications and/or 
advances in data communication protocols. 

30 The following is a description of the short RNL header fields: 
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Version = The version of the radio network layer header used to 
create the datagram. 

U = Unused Bits available for future use. 

5 

RNLH Size = Radio Network Layer Header Size indicates whether 
the RNL header is long or short. 

Extended address = For messages to the radio network, this field 
10 defines the Source IP Address; for messages from the radio network, 
this field defines the Destination IP Address. 

Transport layer protocol = This field is passed through as defined by 
the Standard EP Header. 

15 

The long RNL header includes these additional fields: 

IDENTIFICATION = Number that uniquely defines all of the 
fragments of the same message from the same source. 



MF = More Fragments. This bit is set if there are more fragments 
coming in the current message. 

Fragment offset = This field tells where this fragment belongs in the 
25 current message. When a message is fragmented, each fragment 

except the last one must be a multiple of 8 bytes long. The fragment 
offset is multiplied by 8 to determine the byte offset. A maximum 
message size may be for example 64K bytes. 



20 



30 



For RDT communications, if the IP datagram includes 512 
bytes oj^less of data, the More Fragments (MF) and Fragment Offset 
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fields are copied from the IP Header. For RDT communications with 
more t h«" 512 bytes, the data gateway further fragments the 
message into bursts of 512 bytes or less. Where the radio is the 
originating or end destination device, the radio does not send or 

5 receive messages longer than 512 bytes and therefore does not 
further fragment messages. When sending to a radio as the end 
device, the data gateway 40 may combine fragmented messages but 
imposes a 512 byte limit on the combined message. In this way, the 
MF and fragment offset fields are eliminated for radio originated/end 

10 messages which simplifies radio prograrnming, i.e, the radio code is 
not required to provide fragmentation support. For datagrams from 
the data gateway 40, the Extended Address is the Source IP Address. 
For datagrams from a Radio Data Terminal (RDT) or a radio as on a 
message originator, the Extended Address is the Destination IP 

15 Address. 

Short and Long Radio Network Layer Headers are converted in 
the data gateway 40 to IP headers after datagrams are sent across 
the Radio Network. The RNL Short Header is transformed into an 
IP Header from the following information: 



20 



25 



Static Fields used in all BP Headers: 

VERSION 0 U bit (unused) 0 

HEADER LENGTH 5 TIME TO LIVE 255 

SERVICE TYPE 0 IP OPTIONS Not Used 

DFbit 0 PADDING Not Used 

Configured Information: The IP Address of the Radio. 



30 



Fields gathered from the Radio Network Data Link Layer: 
Total Length is calculated from the data link layer total length plus 
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10 bytes. The 10 bytes correspond to extra data added for the 
conversion from the radio network layer header to the IP header. 

Fields taken from the Short Radio Network Layer Header: 
5 Unused and Protocol. 

Calculated Field: Header Checksum 

The Vers field is set to the current EP version. Because radios do not 

10 send or receive fragmented messages, the Fragment Offset and MF 
fields are set to zero. The Identification field is set by the data 
gateway to a unique value, e.g., by incrementing a counter. 

When the data gateway 40 receives a datagram from the radio 
network, the data gateway converts the Data Link Layer Address to 

15 the Source EP Address using configuration information in the data 
gateway. The data gateway uses the Extended Address in the RNL 
Header as the Destination IP Address. When the radio or RDT 
receives a datagram from the data gateway, it uses the Extended 
Address in the long Radio Network Layer Header as the Source IP 

20 Address. The radio or RDT use configuration information stored in 
the radio or RDT for the Destination IP Address if necessary. Since 
terminating devices in the network must be configured with an IP 
address, the network layer on those devices inserts its own IP 
address as the destination IP address. This is the case simply 

25 because the radio or RDT is a "terminating" network device rather 
than an intermediate network device. 

Figure 6 is a flowchart which illustrates procedures at the 
network and data link layer protocols for data transmissions 
originating from network layer data transceivers to the data gateway 

30 (block 100). For purposes of simplicity in the following flowcharts 
showq^in Figures 6-12, only the radio and RDT are used as network 
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layer data transceivers. However, these procedures apply equally as 
well to other network layer data transceivers described above. Blocks 
102-110 describe network layer processing at the RDT and/or radio. 
A logical decision is made whether the data originates from the radio 
5 or the RDT. If the data originates from the radio, the radio 

generates a short radio network layer header in accordance with the 
procedures outlined in the flowchart in Figure 8 and adds that short 
radio network layer header to each datagram to be tr ansmi tted (block 
104). For data originating from the RDT, the RDT generates a long 

10 radio network layer header as outlined in the flowchart in Figure 9 
and adds that long radio network layer header to each datagram to 
be transmitted (block 106). The RDT then transmits the datagram to 
the radio (block 108) over the serial link using a radio data interface 
(RDD or equivalent protocol. . The radio then transmits the radio 

15 network layer datagram over the RF link (block 110) (DCS) using the 
data channel signalling (DCS) protocol. 

Blocks 112-122 describe data link layer processing at the data 
gateway. Since the present invention envisions more than one type 
of network layer data transceiver attached or associated with one 

20 radio (in the flowchart examples there are only two — the radio and 
the RDT), the data gateway maintains a data transceiver 
configuration table that specifies the configuration of those 
transceivers in the RF network. Over the radio network, messages 
must be routed to one radio ID corresponding to that radio. 

25 Nevertheless, each network layer data transceiver including the radio 
needs a separate network IP address for routing messages at the 
network level. Thus, for each unit type (Le., each different network 
. layer transceiver) associated with the single radio and therefore a 
single radio ID, the data transceiver configuration table stores the 

30 unit type and radio ID along with a unique IP address and the 
version of the network layer protocol being used by that data 
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transceiver. Using the radio ED and unit type, the data gateway 
obtains the unique IP address of the data transceiver which 
originated the data message (block 120). 

Data bursts (or frames) are received at the data gateway (block 
5 112), and the data gateway determines whether the radio originated 
the data bursts (decision block 114). If the RDT originated the data, 
the unit type is equated to an RDT (block 118). Otherwise, the unit 
type is equated to a radio (block 116). The IP address information for 
that data transceiver is obtained by the data gateway accessing the 

10 data transceiver configuration table with the radio ID and unit type 
(block 120). The data gateway then converts the radio network layer 
header to the IP header in accordance with the steps outlined in the 
flowchart in Figure 9 and transmits the IP datagram on the Ethernet 
Network 12 connected to the data gateway (block 122). 

15 Figure 7 is a flowchart diagram illustrating example 

procedures for generating a short radio network layer header (block 
130). The version bits are set to the version of the radio network 
layer protocol in use by the radio, and the unused bits are set to zero 
(block 132). The network layer header size is set by the radio to 

20 indicate that it is a short radio network layer header (block 134). 
The extended address field in the header is set by the radio as the 
destination IP address (block 136). Radios may be programmed with 
the destination IP address or the host IP application sends its IP 
address to the radio via some upper layer (e.g., application layer) of 

25 the OSI model. Alternatively, the radio waits for a host originated 
message before sending any messages to that host The extended 
address field for a radio destined message from the host contains the 
host's IP address. The transport layer protocol is set to that which is 
currently in use between the host and radio applicationsOblock 138). 

30 Figure 8 is a flowchart diagram illustrating example 

procedures for generating a long radio network layer header (block 
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140). The version bits are set to the version of the radio network 
layer protocol currently in use by the RDT, and the unused bits are 
set to zero (block 142). In block 144, the network layer header size 
bits are set to indicate a long radio network layer header (block 144). 
5 The identification, MF bit, fragment offset bit, and protocol fields are 
copied from the IP header into the long radio network layer header 
(block 146). The destination IP address is copied from the IP header 
to the extended address of the long radio network header (block 146). 



10 procedures for converting a radio network layer header to an IP 
packet header of the data gateway (block 150). The data gateway 
sets the version, header length, service type, DF (Don't Fragment) 
bit, and time to live fields to their known static values (block 152). 
The data gateway sets the source IP address to the IP address 

15 configured in the data transceiver configuration table described above 
for this unit-type and radio/logical ID (block 154). The protocol field 
is copied from the RNL header into the IP header (block 156). A 
decision is made in block 158 whether the RNL header is short or 
long. If it is long, the data gateway copies the identification, MF bit, 

20 and fragment offset fields from the long RNL header into the IP 
header (block 160). Otherwise, the data gateway sets the 
identification to an incrementing, non-zero value. The MF bit and 
fragment offset fields are set to zero because the radio is not 
permitted to send fragmented messages (block 162). The data 

25 gateway then copies the extended address field from the radio 

network layer header (included in both the short and long headers) to 
the destination address of the IP header (block 164). The total length 
is set based on the length already present in the data link layer plus 
10 bytes (block 166). The header checks on this calculation and then 

30 " inserts it into the reconstructed IP header (block 168). 



Figure 9 is a flowchart diagram illustrating example 
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The flowchart in Figure 10 illustrates example procedures 
performed at the network and data link layer levels for data 
transmissions originating from the data gateway destined for either 
the radio or some other device associated with the radio (block 170). 
5 Using the IP destination address in the IP header of the datagram 
being sent from the data gateway, the data gateway accesses the 
data transceiver configuration table to obtain the appropriate 
configuration information for that IP address, e.g., the corresponding 
radio or logic ID needed to transmit messages over the radio network, 

10 the unit type, and the network layer version (if any). If a 

corresponding device configuration record is not obtained for that IP 
address (block 174), an error message is generated (block 176). 
Otherwise, control proceeds to block 178 where the data gateway 
converts the IP header of the datagram to a long radio network layer 

15 header in accordance with the procedures outlined in Figure 11. The 
procedures performed in blocks 172-178 correspond to the network 
layer processing at the data gateway. 

The procedures corresponding to blocks 180-202 correspond to 
data link layer processing performed by the data gateway and by the 

20 radio/radio data terminal. From the data transceiver configuration 
record previously obtained in block 174, the data gateway determines 
whether the unit type for the data message to be transmitted 
corresponds to the radio itself or to the RDT associated with the radio 
(block 180). If the unit type corresponds to the radio, the datag ram 

25 is routed by data gateway 40, data interface module 38, and the 
appropriate site 22, 23 for transmission over the appropriate RF 
channel to the ra dio (block 184). If the unit type corresponds to the 
RDT, the da tag ram i s(routedto theappropriate^s^ 
over the assigned RF channel to the radio (block 186). A decision is 

30 then made by the radio in block 188 whether the data received is for 
the radio or for the RDT which the radio can determine by processing 
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the RNLH size field of the radio network layer header attached to the 
received data. If the data is for the RDT, the radio forwards the data 
to the RDT (block 190), and the RDT extracts the RNL header 
information (block 192) including the RNL transport layer protocol to 
5 be used for further communications processing by the RDT. The RDT 
then processes the data message in accordance with the procedures 
outlined in Figure 12 (block 194). If the data received is for the 
radio, the radio processes the RNL header size field (block 198) and 
the RNL transport protocol (block 200). Since the radio now knows 

10 the message is intended for the radio, it "jumps" over any extra fields 
in the header and directly processes the data (block 202). This is 
advantageous because the data gateway uniformly form at s ^all 
messages intended for data transceivers as long radio network laye r 
messages, and the radio determines whether the message is for it by 

15 processing just a few of the first fields in the header or passes the 
message along to the intended data transceiver associated with that 
radio. A further advantage is that the radio programming code is 
simplified by not having to support fragmentation and re-assembly of 
datagrams. 

20 Figure 11 is a flowchart diagram illustrating the procedures for 

converting an D? packet header to a radio network layer header at 
the data gateway (block 210). If the unit type is a radio, the data 
gateway 40 combines fragments of the message if necessary (block 
211). Further, if length of combined message exceeds the data link 

25 layer m^yimnm size, then an error message is generated (block 212). 
The data gateway fragments the datagram if necessary to meet 
tnaYiTT^iTTi size requirements (block 213). The MF bit and fragment 
oflset field bits in the RNL header are set based on the fragmentation 
carried out in block 212 (block 214). Unused bits are set to zero 

30 (block 216), and the data gateway copies the identification and 

protocol fields from the IP header into the RNL header (block 218). 
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The source IP address is copied directly from the IP header into the 
extended address field of the RNL header (block 210). If there are 
more fragments in the datagram (block 222), control returns to block 
214. 

Figure 12 is a flowchart diagram illustrating the procedures for 
converting a radio network layer header to an IP header at the radio 
data terminal. The unused bit field is set to zero (block 232), and the 
version, header length, service type, DF bit, and time to live fields 
are set to their static values which are stored in the RDT (block 234). 
Next, the destination IP address is set to the IP address configured 
for this particular RDT (block 236). The identification, MF bit, 
fragment offset, and protocol fields from the RNL header are copied 
into the reconstructed IP header (block 238). The extended address 
from the RNL is copied into the source address field of the 
reconstructed IP header (block 240). The total length field of the IP 
header is set based on the length already present in the data layer 
plus 10 bytes (block 242). The header checks on and is calculated 
and inserted into the reconstructed IP header (block 244). 

While the invention has been described in connection with 
what is presently considered to be the most practical and preferred 
embodiment, it is to be understood that the invention is not to be 
limited to the disclosed embodiment, but on the contrary, is intended 
to cover various modifications and equivalent arrangements included 
within the spirit and scope of the appended claims. 
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WHAT IS CT^ATMT?/n TS- 



1 1. In a data communications system where data messages 

2 having a header and an associated data portion are communicated 

3 between entities that interact over a network using a standard 

4 internetwork protocol (IP) and where the network includes a radio 

5 link connected to a radio associated with one or more radio entities, a 

6 method comprising: 

7 formatting a data message using one of a first and second 

8 radio network layer (RNL) header formats, both of the first and 

9 second RNL header formats supporting the standard internetwork 

10 protocol but differing from a standard IP header in that 

11 predetermined bits are omitted from the standard IP header attached 

12 to each data message, and 

13 transmitting the formatted data message over the radio link. 

1 2, The method in claim 1, wherein the first RNL header 

2 format includes fewer bits t-h«™ the second RNL header format. 

1 3, The method in claim 1, wherein the first RNL header 

2 format includes fewer bit fields thfl" the second RNL header format. 

1 4. The method in claim 2, wherein if the data message is 

2 originated by the radio, the data message is formatted using the first 

3 RNL header format. 

1 5. The method in claim 3, wherein the initial bit fields in the 

2 first and second RNL headers are the same. 
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1 6. The method in claim 2, wherein if the data message is 

2 originated by the one radio entity, the data message is formatted 

3 using the second RNL header format. 

1 7. The method in claim 1, wherein if the data message is 

2 destined for either the radio or the one radio entity, the data message 

3 is formatted using the second RNL header format* 

1 8. The method in claim 1, wherein the first and second RNL 

2 headers include a RNL size field that indicates whether the header is 

3 the first or the second RNL header. 

1 9. The method in claim 8, wherein the radio processes the 

2 RNL size field of a data message received over the radio link and 

3 passes the data message onto the one radio entity if the RNL size 

4 field indicates the second RNL header. 



1 10. The method in claim 1, wherein a data gateway receives 

2 radio transmissions over the radio link and adds one or more bit 

3 fields to the RNL header of a data message received over the radio 

4 link to convert that RNL header into a corresponding standard IP 

5 header before further transmitting the received data message over 

6 the network. 

1 11. The method in claim 1, wherein a data gateway receives 

2 radio transmissions over the radio link and adds a greater number of 

3 bits to the first RNL header of a data message received from the 

4 radio link to convert the first RNL header into a corresponding 

5 standard IP header before transmitting the other message over the 

6 network than for a data message received with the second RNL 

7 header. 
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1 12. The method in claim 1, wherein a data gateway receives 

2 radio transmissions over the radio litilr and determines an IP address 

3 for a data message received over the radio link based on an 

4 identification number associated with the radio and a type of the 

5 radio entity originating the data message. 

1 13. A packet-based communications system permitting data 

2 communications between a first data processing unit associated with 

3 a computer communications network and a radio associated with a 

4 radio communications network having more limited communications 

5 bandwidth than the computer communications network, each packet 

6 of information including a header portion and a data portion, wherein 

7 certain bits in the header portion of a data packet originated at the 

8 radio are omitted before transmitting the data packet over the radio 

9 network from the computer communications network. 

1 14. A communications system permitting data 

2 communications between a first data processor associated with a 

3 wireline communications network and a radio associated with a radio 

4 communications network having more limited communications 

5 bandwidth than the wireline communications network to transmit 

6 packets of information, each packet including a header portion and a 

7 data portion, wherein certain bits in the header portion of a data 

8 packet finally destined for the radio are omitted before transmitting 

9 the data packet over the radio network from the wireline network. 

1 15. A communications system according to claim 14, wherein 

2 the radio network further includes a second data processor connected 

3 to the radio and wherein certain bits in the header portion of a 

4 second data packet finally destined for the second data processor are 
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5 omitted before transmitting the second data packet over the radio 

6 network from the wireline network. 

1 16. A communications system according to claim 14, further 

2 comprising: 

3 a data gateway connected to the wireline network and 

4 receiving data packets transmitted over a radio HnV by the radio, 

5 wherein the data gateway adds certain communications protocol bits 

6 to the header portion of a second data packet received over the radio 

7 link before sending the second data packet over the wireline network. 

1 17. A data communications system for transmitting data 

2 messages, each data message including a header and associated data, 

3 comprising: 

4 first and second communications networks connected by a 

5 radio link, the first network using a standard internetwork protocol 

6 (IP); 

7 plural computing devices included in the first network; 

8 a data gateway connected to the first network and interfaced 

9 with one end of the radio link; and 

10 a radio and a radio associated device included in the second 

11 network, the radio connected at an opposite end of the radio link and 

12 a radio communications protocol being used for data communications 

13 over the radio linV 

14 wherein for data messages from the first network intended for 

15 the radio or for the radio associated device, the data gateway removes 

16 a first number of bit fields of a standard TP header for each data 

17 message to obtain a first modified network header, and for data 

18 messages originated from the radio intended for the first network, the 

19 radio attaches to each data message a second number of bit fields to 
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20 obtain a second modified network header, the second number being 

21 smaller than the first number. 

1 18, The system in claim 17, wherein the first network is a 

2 wireline network including a plurality of computers. 
1 

1 19. The system in claim 17, wherein the initial bit fields in the 

2 first and second modified network headers are the same. 

1 20. The system in claim 17, wherein the second modified 

2 network header includes a pniniTnal amount of information to support 

3 network communications according to the standard IP. 
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TO THAT CURRENTLY IN USE 







134 



136 





SET THE VERSION BITS TO 
VERSION OF RNL PROTOCOL 
IN USE BY THE RDT AND SET 
UNUSED BITS TO 0 



142 







SET THE RNLH SIZE 
TO INDICATE LONG 


l 


COPY THE IDENTI 
FRAGMENT OFFSE 
FIELDS FROM ' 
TO THE LONG 


FICATION, MF BIT, 
■T, AND PROTOCOL 
rHE IP HEADER 
i RNL HEADER 



144 



146 



COPY THE DESTINATION IP 
ADDRESS FROM THE IP HEADER 
TO THE EXTENDED ADDRESS 
OF THE LONG RNL HEADER 



148 




CMRSTmiTF SHFFT mill F 26^ 
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RNLr*-IP 
AT DATA GATEWAY 




150 



SET THE VERSION, HEADER LENGTH, 
SERVICE TYPE, DF BIT, AND TIME TO 
LIVE TO THEIR STATIC VALUES 



\ 152 

Y 



SET THE SOURCE IP ADDRESS TO 

THE IP ADDRESS CONFIGURED 
FOR THIS UNIT TYPE AND RADIO ID 



I 



COPY THE PROTOCOL FIELD FROM 
THE RNL HEADER TO THE IP 
HEADER 



NO 



160 




154 



156 



158 



YES 



162 



COPY THE IDENTIFICATION, MF BIT, 
AND FRAGMENT OFFSET FIELDS 
FROM THE LONG RNL HEADER TO 
THE IP HEADER 



SET IDENTIFICATION TO 
INCREMENTING NON ZERO VALUE. 
SET MF BIT AND FRAGMENT 
OFFSET TO ZERO 



COPY THE EXTENDED ADDRESS 
FIELD FROM THE RNL HEADER 
TO THE DESTINATION ADDRESS OF 
THE IP HEADER 



164 



SET THE TOTAL LENGTH TO THE LENGTH f 166 



FROM THE DATA LINK LAYER (DLL) + 
10 BYTES 



CALCULATE THE HEADER CHECKSUM 



^ RETURN 



~k 168 

\ 



~. .norm rrc CWPPT mi ILE 26^ 
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RADIO NETWOR 



170 



USING IP DESTINATION ADDRESS IN THE 
IP HEADER, OBTAIN DEVICE CONFIGURATION 
INFORMATION FOR THAT IP ADDRESS 




nl processing 
dlCprocessing 



CONVERT IP HEADER OF DATAGRAM 
TO LONG RNL HEADER AT DATA 
GATEWAY (SEE FIG. 11) 



I 



180 



RADIO 



UNIT TYPE= 



RDT 



184 

V 




.RADIO OR RDT^X 
— ^T^^ - *^ 




186 
/ 


GENERATE RADIO DESTINED 
DATAGRAM AND TRANSMIT 
OVER RF CHANNEL TO RADIO 




GENERATE RDT DESTINED 
DATAGRAM AND TRANSMIT 
OVER RF CHANNEL TO RADIO 





RDT 



190 




FORWARD TO RDT | 






PROCESS RNL HEADER 1 
FIELDS I 






PROCESS 1 
DATA MESSAGE 1 



IS THE 
DATA RECEIVED^ 
: OR RADIO OR RD1 



188 



RADIO 



PROCESS RNL HEADER 
SIZE FIELD 



198 



{ 



| 192 

r 



PROCESS RNL 
TRANSPORT PROTOCOL 



1 194 



JUMP TO AND 
PROCESS DATA 



200 



I 



1202 



END 

ci irqtiti ITF SHEET (RULE 26) 




n • i » 
• - 
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IP-.-RNLAT 
DATA GATEWAY 




210 



IF UNIT-TYPE IS RADIO THEN 
COMBINE FRAGMENTS IF MSG 
IS FRAGMENTED 



IF UNFRAGMENTED MSG SIZE 
> 512 THEN ERROR MSG 



FRAGMENT THE IP DATAGRAM 
IF NECESSARY TO MEET 
MAXIMUM SIZE 



Y 

* 212 

Y 

\ 213 

r 



SET THE MF BIT AND FRAGMENT OFFSET 
FIELD IN THE RNL HEADER BASED 
ON THE FRAGMENTATION 



I 214 

r 



SET UNUSED FIELD 
BITS TO 0 




COPY THE IDENTIFICATION AND 
THE PROTOCOL FIELDS FROM THE IP 
HEADER TO THE RNL HEADER 




YES 



COPY THE SOURCE IP ADDRESS FROM 
THE IP HEADER TO THE EXTENDED ADDRESS 
FIELD OF THE RNL HEADER 



222 



| 220 

r 




Qf fRSTITI ITF SHFFT (RULE 26* 
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c 



RNL-^IP AT 
THE RDT 




230 



SET THE UNUSED BIT TO 0 



SET THE VERSION. HEADER LENGTH, 
SERVICETYPE.DF BIT, AND TIME TO LIVE 
FIELD TO THEIR STATIC VALUES 



232 



234 

Y 



SET THE DESTINATION IP ADDRESS TO THE 
IP ADDRESS CONFIGURED FOR THIS RDT 




COPY THE IDENTIFICATION, MF BIT, FRAGMENT 
OFFSET, AND THE PROTOCOL FIELDS FROM 
THE RNL HEADER TO THE IP HEADER | 




COPY THE EXTENDED ADDRESS FROM 
THE RNL HEADER TO THE SOURCE ADDRESS 
OF THE IP HEADER 



\ 240 



SET THE TOTAL LENGTH TO THE LENGTH 
FROM THE DATA LINK LAYER (DLL)+10 BYTES 




CALCULATE THE HEADER CHECKSUM 



} 



244 



SUBSTITUTE SHEET (RULE 26) 



